Open Bug 469421 Opened 16 years ago Updated 2 months ago

Add a folder column to search results for bookmarks in the library

Categories

(Firefox :: Bookmarks & History, defect, P5)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect

Tracking

()

People

(Reporter: faaborg, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

Show Parent Folder 2.1.1 for interested users
10.67 KB, application/x-xpinstall
Details
overlay3.7.js - JS file from "Show Parent Folder" for reference
3.82 KB, text/plain
Details
469421-parent-folder.patch - WIP (v2)
13.62 KB, patch
mak
: feedback-
Details | Diff | Splinter Review 
When searching in the library window, there should be a column to display where the search results reside in the user's bookmark collection.  This should only apply to the "All Bookmarks" context (selected folder and history are obvious as to the location).
Blocks: 469426
An even more useful way to map search results to their folders 
was the way search used to work in netscape 4 (!) - the search results 
were shown within the normal bookmarks folder hierarchy, you could 
step through them and sub-folders were opened on demand.
I guess this would be a fine alternative solution of this issue.
(In reply to comment #4)
> An even more useful way to map search results to their folders 
> was the way search used to work in netscape 4 (!) - the search results 
> were shown within the normal bookmarks folder hierarchy, you could 
> step through them and sub-folders were opened on demand.
> I guess this would be a fine alternative solution of this issue.
That's bug 171575.

In the future, please don't post the same comment to multiple bugs that are related, because then someone else has to post a comment answering you, and telling you to not do that.  This bug is for adding the column - please do not try to change what it is doing.
[replying to Shawn with 3 comments; ignore for bug evaluation]

Only after commenting the other bug I noticed it was closed as a duplicate, sorry for that. Of course, the comment belonged in the open instance of the bug then.

> please do not try to change what it is doing
The bug report is motivated by a use case. Analyzing the scenario may help to resolve the bug, as it is done in other bugs as well by many people, including you. This kind of analysis includes alternative proposals. I would have referred to https://bugzilla.mozilla.org/show_bug.cgi?id=171575 if I had been aware - sorry also I had not researched it.

Moreover, referring to another bug as you did is not really constructive to resolve an actual problem if that other bug is a WONTFIX (to which you contributed yourself if I interpret that bug discussion properly).
This is even more annoying as this is one of the two bugs I know that are persistently ignored despite good arguments and no counter-arguments.
A contemplation for the eventual developer who implements this enhancement ...

The word 'Location' appears to be too generic for both its current use and certainly its next use once a "folder location" column is added.  The location of the bookmark is not actually on the Web, it is on the local machine.  The content of the bookmark points to something on the Web.  Perhaps you could use the column labels "Local Folder" and "Web Target" for an improved contrast of meaning.
This should certainly be in Firefox, in the meantime can be covered by installing  the  "Show Parent Folder" extension by Alice White (name is listed in CC list) https://addons.mozilla.org/firefox/7372  Choose the add-on option   'Show Folder hierarchy'.
In Organize Bookmarks,  right-click on column header (or use View menu)  to add
the "Parent Folder" column.  You can  drag to rearrange and/or resize columns, 
You will want the Parent Folder column fairly wide to see the hierarchy.
Although this is about adding a column to the Library list, a possible sidebar issue in Bug 482029 was pointed here, so will point out that there is another add-on also by Alice White that can be used in both the sidebar (Ctrl+B) and the Library list (Ctrl+Shift+B) to locate you to the parent folder of a bookmark with the right-click context menu.  "Go Parent Folder" https://addons.mozilla.org/firefox/7377    This is not an alternative to adding a column to the Library list, but it is a good companion extension.  Both should be in Firefox.
>to locate you to the parent folder of a
>bookmark with the right-click context menu.  "Go Parent Folder"
>https://addons.mozilla.org/firefox/7377    This is not an alternative to adding
>a column to the Library list, but it is a good companion extension.

I agree. I think we currently have this covered with bug 469441, but please comment there if the functionality is different.
Platform/OS -> All

The Seamonkey equivalent of this bug is bug 56418 (currently with 83 votes).
OS: Mac OS X → All
Hardware: x86 → All
In bug 469416 (Add "Folder" to the properties pane of bookmarks when viewing search results), I attached a sample UI (attachment 392021 [details]) which includes the folder column proposed by this bug and SM bug 56418. It also includes
- "View containing folder" button (bug 469441)

With respect to this bug, I assume Folder column should show full path within the All Bookmarks context. We'll need to agree on a separator between nested folders, I am proposing colon (:), since it's not a file system path.
Comments welcome.
>We'll need to agree on a separator between nested
>folders, I am proposing colon (:), since it's not a file system path.
>Comments welcome.

I think for the contents of the folder column we will probably want to go for
a format with slashes, similar to a URL:

folder/subfolder/subsubfolder

the reason being that we are thinking about exposing these bookmark paths in
the location bar, and allowing users to actually navigate on them, so it makes
sense to follow a syntax similar to URLs.

>since it's not a file system path.

the forward vs. backslash distinction is subtle, but should help to show that this isn't a file system path. Also, if we are syncing all of your bookmarks with Weave, and you enter this path into the location bar, it is sort of a private URL-ish thing.
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
*** Bug 531264 has been marked as a duplicate of this bug. ***

This is not really the case: Bug 531264 is rather a duplicate of Bug 171575 - see Comment #5, because it is about the tree view common to old Netscape 4.

The related bug unfortunately is "verified wontfix" w/o any reason given, and either it should be reopened or 531264 left open.

Is there a special problem with this, being essentially open since 2003?

Thanks! Simon
>Is there a special problem with this, being essentially open since 2003?

I think there has been some confusion around wontfixing a bug because we don't like that very specific approach proposed, but still being eager to address the overall problem.  This also makes it hard to set duplicates, since multiple bugs are proposing the same ability, just with different interfaces.
A wiki page for discussion on problem and possible solution for the same. At least we won't get cc mail for every clarification :)
(In reply to comment #22)
> A wiki page for discussion on problem and possible solution for the same. At
> least we won't get cc mail for every clarification :)
If you only care about the bug being fixed or not, I suggest you instead vote for it.  You can get e-mails when bugs you vote for change state, but you won't get e-mail for comments (by default, AFAIK).

Comments clarifying behaviors are exactly what bugzilla is designed for.
A straightforward implementation which should resolve this issue:

1) Add optional "Containing Folder" column to Library's list control.
2) Add "Open Containing Folder" to Library's list item context menu.

Both enhancements are additive and low-risk, i.e. they don't affect existing behaviors and thus shouldn't generate objections. "Containing folder" is a widely accepted term which avoids overloading "location". 

This proposal was originally submitted as Bug 559521.
Bump for "Open Containing Folder" menu action, which is Chromium does for this.
"Open containing folder" is not the same. When managing a lot of bookmarks I want to see all folders at once, sort by folder, etc. I'm already using one FF extension to see the folder column, and another to go there.
Note that for deeper bookmark trees, this bug avoids that new links can be added to the right folder, thus, organizing your "knowledge" gets impossible. You need to know which matches are in which folder to reorganize the folder hierarchy. I would also vote to have at least an option to include the folder hierarchy into search results.
There are at least 4 outstanding bug or enhancement requests on this topic covering 150+ votes to solve a simple problem which should have been solved a long LONG time ago.

The very simple problem is that when you search for and find one or more bookmarks in ANY part of firefox (v10.0.2 Windows in my case) there is absolutely ZERO way of telling **WHERE** that bookmark came from in your extensive, thousands upon thousands of bookmarks.

You "find" it but you can't really figure out where it CAME from.
There is no way to determine what folder inside of a folder inside of whatever folder that bookmark is located.  You can't go to that folder.

The information is useful and needed because sometimes you are retrieving a bookmark and know it is from a larger batch of bookmarks dealing with the same topic or issue.  You know enough to find one of the bookmarks (via search) but you are dead-in-the-water cause there is no way to find the rest of them or go to the folder holding it.

(Yes, I suppose you could export your entire bookmark list in HTML format, load it up and then search that way, but that isn't really a solution is it?)

There is simple solution/request.

For any bookmark which is retrieved from:
1) the 'anything bar' (or whatever we call the URL searching process);
2) the bookmarks sidebar search, or
3) the "Library Organizer" bookmark search...

All bookmarks from these retrieval/search mechanisms should be able to be right-clicked->properties and show the Folder location (in the bookmarks tree) of the bookmark, *OR* (in the case of the Libaray which has columns) the location should appear, if selected, as one of the column values such as Tags, Last Accessed, etc.

Again...the simple act of finding out where a bookmark came from is impossible using normal means.  These bugs have been here for years and all other browsers I'm aware of do this normally.  What is the problem?

Bookmarks can already be right-clicked and choose properties.  Can't we just add an extra field to show the bookmark location??  Library organize already has columns for all the other bookmark attributes, can't one be added to show location?

(PS: the use of the word "Location" on bookmark attributes to denote "URL" is just extra confusing if/when the actual bookmark TREE location is included.  I don't know what you call the new attribute if "Location" is already used for "URL", but I digress.)

FYI: I found the following bug tickets addressing the same basic issue (I'm sure there are more.  I only waded through about 150 before giving up.)  Could someone consolidate them (and the votes!) as well?

BUG: 469416
BUG: 56418  (From year 2000!!!)
BUG: 527225
(In reply to k73qq55wftttt2chb424 from comment #37)
> There are at least 4 outstanding bug or enhancement requests on this topic
> covering 150+ votes to solve a simple problem which should have been solved
> a long LONG time ago.

Don't waste your time/effort. If they decided to don't give a **** about something they won't no matter what you do. Its the same with embedded flash and various others.
This add-on implements the feature:
https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/

It should not be difficult to integrate it in the firefox core...
(In reply to avada from comment #38)
> (In reply to k73qq55wftttt2chb424 from comment #37)
> > There are at least 4 outstanding bug or enhancement requests on this topic
> > covering 150+ votes to solve a simple problem which should have been solved
> > a long LONG time ago.
> 
> Don't waste your time/effort. If they decided to don't give a **** about
> something they won't no matter what you do. Its the same with embedded flash
> and various others.

It certainly seems so.
Priority: -- → P4
This feature request has so many duplicates that a combined number of votes must be breaking through the roof. And still nobody at Mozilla cares about it. Probably because they don't use Bookmarks themselves. Well, start using them and you'll notice the same problem.
(In reply to Zex from comment #45)
> This feature request has so many duplicates that a combined number of votes
> must be breaking through the roof. And still nobody at Mozilla cares about
> it. Probably because they don't use Bookmarks themselves. Well, start using
> them and you'll notice the same problem.

Hi, I can esnure you mozilla developers use bookmarks (and also obscure features of them), the problem is that implementing this properly and in a performant way requires an expensive refactoring and there's no resources to work on that. As in any other large project, selling refactorings as things-we-should-spend-time-on is hard, cause they don't bring tangible immediate benefits to the project.
I wonder for whom the project is intended to be.
Saving thousands of users headaches and minutes of their lives for every non-trivial search - is that not any "tangible immediate benefit"? Isn't that worth some effort‽
@Zex, @Thomas Wolf, @anyone-else-who-wants-this-functionality
This will likely never get implemented, the way things work. 

Just use these:
https://addons.mozilla.org/firefox/addon/show-parent-folder/

https://addons.mozilla.org/firefox/addon/sidebar-bookmarks-search-plus/

https://addons.mozilla.org/firefox/addon/go-parent-folder/

And forget about it.
We have already seen suggestions how to implement this without refactoring. One such suggestion is this one: 

When the user right-clicks and chooses Properties of the link, and when the Properties window opens, it can show all the folders where the link exists.

This can be implemented simply by taking the link, and then searching (again) through the folder tree, listing the folders which contain that link. Since it happens only when the Properties window is open, it doesn't matter that

But to be honest, I don't understand why it requires a lot of refactoring? All that has to be refactored is part of the search algorithm (to memorize folders), and the display window (to show one more column). However, if that is complicated, the above algorithm still solves the problem.
In the previous post I wanted to say: "...it doesn't matter that it's searching again, because those few milliseconds lost on the second search happen only in the Properties window, too fast for the user to notice".

Regarding the plugin, thank you @avada, but it's not very useful when I'm searching in the sidebar (you know, Ctrl+B).
(In reply to Zex from comment #50)
> In the previous post I wanted to say: "...it doesn't matter that it's
> searching again, because those few milliseconds lost on the second search
> happen only in the Properties window, too fast for the user to notice".
> 
> Regarding the plugin, thank you @avada, but it's not very useful when I'm
> searching in the sidebar (you know, Ctrl+B).

What do you mean? Two of them work on the sidebar and give you the ability to jump to the parent folder, or even to show the item's location in the folder structure. Frankly I rarely even use the library. No need.
I apologize, Avada. You're totally right. I tried only the first one, but those other two addons kick ****.

So, Marco Bonardo, how come that someone can make external addon without "refactoring entire Firefox", while core developers can't do it??
You already answered your question in the question itself. Add-on authors don't have to cope with core quality standards. And that's great for prototyping things and cause they can do things at a faster pace. It's not great when you instead want to ship the feature to hundreds millions users, rather than 9k users. A core user cannot just "uninstall" the feature if it creates problems, like you can do with an add-on.
If you notice, none of the add-ons is showing the complete path for each entry, because without a refactoring it's very expensive. And it's what we'd like to do, because what happens when you have 2 folders with the same name but different paths in your search result?
Some add-ons are showing the parent folder name, that already has a non-ignorable cost. You may not notice the perf hit maybe cause your search has a small resultset, or because you have a fast computer. We can't make the risk to break users on less powerful computers just to throw out a rushed feature.
It's great Firefox has add-ons, but it's not given that what is easy to do in an add-on is also easy to ship to everyone.
Priority: P4 → P5
(In reply to avada from comment #48)
> @Zex, @Thomas Wolf, @anyone-else-who-wants-this-functionality
> This will likely never get implemented, the way things work. 
> 
> Just use these:
> https://addons.mozilla.org/firefox/addon/show-parent-folder/
> 
> https://addons.mozilla.org/firefox/addon/sidebar-bookmarks-search-plus/
> 
> https://addons.mozilla.org/firefox/addon/go-parent-folder/
> 
> And forget about it.

Well, with e10s and Legacy Addons (e.G. XUL) being disabled in the end of next year, this is not really a solution to forget about the problem.
(In reply to dfgsdfgsdfg from comment #55)
> Well, with e10s and Legacy Addons (e.G. XUL) being disabled in the end of
> next year, this is not really a solution to forget about the problem.

It is. After that happens you just won't have this functionality at all. And that's that.
After that happens and with this answers many users will leave Firefox. And that's that.
Bug exists in Firefox 52. 
I use https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder as a temporary solution.

Please fix this bug inside Firefox.
Some computer users do not know about addons, but they use Firefox' bookmarks.
It seems that Mozilla does not want to fix this bug in Firefox and in the SeaMonkey.
Switching to Google Chromium/Chrome is not an option. 
Firefox is shipped by default on most GNU/Linux distributions. So this bug should be fixed as soon as possible.

I'm attaching latest Show Parent Folder 2.1.1 for interested users.
i compared Chrome and Firefox ways to store bookmarks:
Chrome uses a simple JSON with hierarchies.. so i guess that it makes a runtime list of all bookmarks, making it very easy to know a node's parent.
Firefox uses a SQLite db where the parent is an id. i guess that the query overload is what they say (making a lot of JOINs in queries)

i think that adding a "show in folder" action menu shouldn't add any overload and would allow everybody to manage big bookmark list

or if Firefox bookmarks were saved in JSON we could edit them externally
Flags: needinfo?(mak77)
not sure why you're needinfo-ing me, I don't have much to add to what I already said. The storage format doesn't matter, Chrome keeps all the bookmarks in memory and saves them periodically, and that makes things easier, apart if the user has many thousands bookmarks. We try to be a bit more memory efficient. There are solutions also for our setup (for example an adjacency table) but someone has to code those, and I don't have the time atm.
Flags: needinfo?(mak77)
(In reply to Valdo from comment #74)
> Wondering why...

Maybe there's just no available staff to fix it? The Firefox codebase is huge, and the number of developers compared to similar projects is a tiny fraction. Mozilla is not Google, resources are limited.

Now, continued advocacy won't bring us anywhere, but this is open source, so if anyone has time to contribute a well made fix, that'll be welcome. Otherwise it will be fixed when some dev finds the time to fix it, or when a bookmarking experience redesign will be resourced.
Clearing tracking for 57 based on the rationale in bug 196509, comment 104.
tracking-firefox57: ? → ---
I'm stealing code from Alice White's "Show Parent Folder" add-on, so here's the relevant code for reference.
Assignee: nobody → jorgk
Status: NEW → ASSIGNED
This works and shows a column "Parent Folder". Sorting doesn't work, I'm not sure whether that ever worked with the add-on.

I think it's about time this gets implemented given the number of duplicates and votes. I'm happy to see it through since I have some spare cycles.

Marco, could you please look at the patch and give me your feedback. It's mainly a cut&paste job from the add-on, including hunks I don't understand :-(

What's needed to get sorting going? Or shall we not allow sorting on the column?
Attachment #8929654 - Flags: feedback?(mak77)
I've added a few hunks to get sorting by "Parent Folder" going. This now sorts, but by the content of tags since I haven't provided a comparison function for the parent folder column yet. Marco, could you please advise how that needs to be done since the parent folder is this loopup
  select title from moz_bookmarks where id=:parent;
Can't we just use the sell content from the UI?

Also I noticed that in the UI the column doesn't have the small sort direction indicator arrow (in German that would be: Sortierungsrichtunganzeigepfeil ;-)). So I must be missing something else.

I'm also wondering whether we should Alice's original idea to concatenate the folder hierarchy into the column by default as you can see in attachment 8929652 [details]:

while ( (FolderId = bmsvc.getFolderIdForItem(parentFolderId)) ){
  if (FolderId == parentFolderId)
    break;
  parentFolderId = FolderId;
  var text = bmsvc.getItemTitle(parentFolderId);
  if (!text)
    break;
  folderTitle = text + " /"+ folderTitle;
}
Attachment #8929654 - Attachment is obsolete: true
Attachment #8929654 - Flags: feedback?(mak77)
Attachment #8929696 - Flags: feedback?(mak77)
Comment on attachment 8929696 [details] [diff] [review]
469421-parent-folder.patch - WIP (v2)

Review of attachment 8929696 [details] [diff] [review]:
-----------------------------------------------------------------

Heh, it's not that easy.
Apart from the synchronous I/O issue I show later, that is a no-go by itself, there are another couple UX problems:
1. It's completely pointless to show the parent folder when you are inside a folder. It should be shown only for queries (queries having searchTerms), but that requires bug 412175. Note comment 0 when it says "while searching".
2. If we show only the parent folder, what happens if 2 bookmarks are in a parent folder with the same name, but with different paths, like toolbar/recipes and menu/recipes? You'll just see "recipes", how can you tell where is it? The only solution to this would be to introduce an adjacency table in places.sqlite, so that we can quickly query the path of each bookmark when we query the bookmarks themselves.

All in all, I think it would be simpler for contributors to work on bug 469441, that would have less perf implications because we'd do I/O only when the action is actually required. Though, IIRC the Library requires the full path to be able to open it, thus it would still require a way to get all the ancestors. On the other side that may be simpler because we could go with a one-off async recursive query in SQL to find it on demand.
It would still have some edge-cases like tags and livemarks to keep into account, but nothing crazy to handle.

::: browser/components/places/content/treeView.js
@@ +1571,5 @@
> +          return "";
> +        let bmsvc = Components.classes["@mozilla.org/browser/nav-bookmarks-service;1"]
> +                              .getService(Components.interfaces.nsINavBookmarksService);
> +        let parentFolderId = bmsvc.getFolderIdForItem(node.itemId);
> +        return bmsvc.getItemTitle(parentFolderId);

Unfortunately, as I previously said, we cannot just take the add-on code, because these 2 calls alone would completely kill the treeview performance (it's 2 synchronous queries per each row). It may not be visible in a small folder, but in things like unsorted bookmarks or a large search result it would be quite bad.

The only solution to this, is querying the ancestor information while we query the nodes in nsNavHistory and nsNavBookmarks (when query type is bookmarks). Though, there are quite some edge cases like tags, that would show the wrong thing (likely also with this patch) or throw (livemarks for example?).
Attachment #8929696 - Flags: feedback?(mak77) → feedback-
Thanks for the weekend reply.

(In reply to Marco Bonardo [::mak] from comment #81)
> All in all, I think it would be simpler for contributors to work on bug
> 469441, ...
Maybe that's also more useful since the user would want to go to that folder anyway, I assume. Also, we're not facing the dilemma of showing the entire folder hierarchy in that column.
Assignee: jorgk → nobody
Status: ASSIGNED → NEW
(In reply to Jorg K [Almost not working on Thunderbird (some bustage-fix only) due to non-renewal of contract] from comment #82)
> Maybe that's also more useful since the user would want to go to that folder
> anyway, I assume. Also, we're not facing the dilemma of showing the entire
> folder hierarchy in that column.

You mean to add this to the sidebar also? Using the library is a fair bit less practical.

Are you familiar the related Sidebar Bookmarks Search Plus addon? I think that's the most useful of these related addons by Alice.
It shows the whole folder structure for the result without having you jump there. It has the advantage that it doesn't navigate the sidebar proper to that location and doesn't open all folders, so you don't have to close all of them by hand after you're finished.
Plus it needn't have the same performance impact of having a path for all results, since the searching and viewing is only performed for one item at a time and only when one selects the item.
Depends on: 408991
This one is pretty good: https://addons.mozilla.org/en-US/firefox/addon/bookmark-search-plus-2/

Creates a small window of search results right below the search input, like a scrollable dropdown menu. Right-click a result and select 'Show bookmark'. You will scroll to that bookmark in your existing list of bookmarks.

I wrote this patch to solve this issue in Waterfox: https://github.com/MrAlex94/Waterfox/pull/843/files . If you think it is an appropiate solution to this bug, I want to port it to Firefox.

I'm sorry but I don't think we want to take a patch using WITH RECURSIVE, it would be a nightmare perf hog in a tree with thousands of entries. We need something more efficient (per bug 408991). If someone wants to look into adding an adjacency table to bookmarks, that's what we need.

I disagree with the performance issues. I am using this patch with 170k+ bookmarks with 276 folders with max depth of 6 for several months did not encounter any problems regarding performance. But if you have different use cases in your mind I can test them too. Also the stackoverflow answer (https://stackoverflow.com/questions/192220/what-is-the-most-efficient-elegant-way-to-parse-a-flat-table-into-a-tree/192462#192462) linked as a reference in bug 408991 is recently updated in July 2018 and suggests using recursive queries also. If I am missing something let me know but I think using CTEs are sufficient solution for bookmark paths.

Please don't change the status/tracking flags, they aren't going to make this be prioritised any differently and just cause unnecessary noise. The fact the bug is open is enough to indicate that it is an issue in the current versions.

status-firefox73: affected → ---
status-firefox74: affected → ---
status-firefox75: affected → ---
status-firefox76: affected → ---

(In reply to Camaleon from comment #141)

I also miss this feature a lot, it would be very useful for users having an old and huge bookmark library.
Searching and finding for a bookmarked site is fine but from a user's order outlook, a bit useless because you can't guess where the page is located under.

Best workaround is to use Bookmark search plus 2. You can get to the folder of bookmark easily. You can also search for bookmark folders. Recently also multi-select, was implemented, which is a huge help.

Shouldn't this bug be resolved now that https://bugzilla.mozilla.org/show_bug.cgi?id=469441 has been fixed?
Add "Open Containing Folder" context menu to search results of bookmarks in the Library window (link to view/open enclosing folder, parent folder button)

How to use:
FF menu > Bookmarks > Manage bookmarks (ctrl-shift-o)
Search for a bookmark > R. click one of the results > click 'Show in folder'
On the left, the containing folder scrolls into view and is highlighted

Please remember that Bugzilla is not a general discussion forum, but a place for working on fixing bugs. Off-topic, advocacy and metoo comments do not help towards fixing the bug. Due to the volume of these types of comments that this bug is receiving, I am restricting the comments.

Please re-review the etiquette before posting again in any bug.

We recognise that this is a pain point for users. As has been mentioned, a contributor recently implemented the right-click option for "Show in Folder" which at least mitigates this a little bit - but not obviously not fully. The way forward for any fixes for this bug would be as per Marco's comment 101. Please do not go commenting on that bug as well, unless you intend to help work on the patch to fix it.

Restrict Comments: true
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 38 duplicates, 111 votes and 127 CCs.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: